フロントエンドエンジニアに捧げるAWS Amplify Console

Amplify Consoleで出来ることを紹介します。

#Amplify Console

#AWS Amplify

#AWS

加藤諒

2020.06.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます、加藤です。今回はフロントエンドエンジニア向けに静的なWebサイトをホスティングなどが出来るサービスであるAWS Amplify Consoleの使い方や出来る事を紹介します。

古の時代、ただの静的なコンテンツを表示する為だけだとしてもサーバーを建ててApache or nginxをインストールして...という事をやっていました。フロントエンドエンジニア or デザイナーが作成し、インフラエンジニアに依頼する必要がありました。古の時代といった通り現代では、NetlifyやFirebase hosting、そして本ブログで紹介するAmplify Consoleを使えば自分自身で簡単に簡単にリリースを行うことができます。より多くのエンジニアにそういった体験をして貰えれば良いなと思いこのブログを書きます。

AWS Amplifyとは

AWS Amplify（以降、Amplify）はモバイル・ウェブアプリケーション向けの開発プラットフォームです。Amplifyの名を関したサービスやツールは大きく分けて3つあります。Amplifyを触り始めた際にこれで混乱される方が多いです。

Amplify CLI
- ローカルからAWSを構築する為のツール
- CLI、TUI操作する事でアプリケーションやAWSがスキャフォールドされる
  - AWSがスキャフォールド = AWS上にリソースを作る為のCloudFormationがスキャフォールドされる
- https://docs.amplify.aws/cli
Amplify SDK
- Web（React・Vue・Angular）・iOS・Android・React Native向けに提供されているSDK
- Amplifyに対応しているAWSサービスをフロントエンドから操作する事ができる
- フロント/バックエンドで分業している場合はAmplify SDKを入れてCognitoとAPI Gatewayのクライアントとしてだけ使うというパターンもある
- https://docs.amplify.aws/start
Amplify Console
- 静的なWebアプリケーションをホスティングするサービス
- Gitリポジトリ（GitHub・GitLabなど）や手動アップロードをソースとして自動・手動デプロイが可能
- 設定に基づいてビルド・単体テスト・E2Eテスト・デプロイまでを制御できる
- Amplify CLIを使用しているプロジェクトの場合はバックエンドまで合わせてデプロイができる
- https://aws.amazon.com/jp/amplify/console/

本ブログでは、最後の項目のAmplify Consoleの特にフロントエンド部分について説明します。ここ実は少し自信がありません...

間違いがあればTwitterでメンションを飛ばして頂けるととてもありがたいです。

Amplify Consoleとは

やりたいこと

Amplify Consoleは様々な機能があるので、漠然と機能を学んでいると「あれ？ところで何をやりたいんだけっけ？」となる恐れがあります。最初にAmplify Consoleを使って何をやりたいのか整理しましょう。

開発者がリポジトリにPull Requestを上げる
Pull Requestを元に自動でビルド・ユニットテスト・E2Eテストが行われ結果がPull Requestに通知される
同時にレビュー用の一時サーバーが立ち上がりアプリケーションをブラウザでプレビュー可能になる
レビューアーがコード・テスト項目・プレビュー環境の動作をチェックしOKならマージする
1. プレビュー環境が削除される
Pull RequestがProdブランチにマージされる
同様のフローでProd環境のサーバーのデプロイされる

これが、自分が思うAmplify Consoleの最もスタンダードな使い方です。

CI/CD

Amplify ConsoleはホスティングだけではなくCI/CD環境も兼ね備えています。この設定にはデフォルト設定とブランチ毎設定の2種類があり、どちらか1つだけが適用されます。

デフォルト設定はAmplify Console環境を作成する際にアプリケーションを自動で判別し最適なものを作成します。紐付けるリポジトリのブランチ内にamplify.ymlが存在する場合はそれを複製します。

デフォルト設定はブランチ毎設定が存在しない場合に利用されます。ブランチ毎設定が存在する場合にマネジメントコンソールからいくら変更しても意味は無いので注意してください。

ブランチ毎設定はブランチのルートディレクトリにamplify.ymlが存在する場合に有効になり、そのファイルの設定を使用します。

version: 1.0
frontend:
  phases:
    preBuild:
      commands:
        - 'nvm use "${VERSION_NODE_12}"'
        - 'yarn install'
        - 'yarn test:ci'
    build:
      commands:
        - 'yarn run build'
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - 'node_modules/**/*'

私は、デフォルト設定は使わずに、ブランチ設定だけを使うのが無駄に混乱せず手間もかからないのがベターを考えそのように運用しています。

CI/CDはデフォルトだとAWSが用意しているDocker Imageの上で実行されます。必要があれば任意のDocker Imageを使用する事ができます。

Pull Request・ブランチ自動連携

Pull Request・ブランチの追加をAmplify Consoleで自動的に検出し連携します。Amplify CLIを使っている場合は、バックエンドを自動的に生成または既存の環境（予め選択して置いたもの）に接続します。接続というのはAWSリソースのARNなど識別子を取得しアプリケーションに設定する事でアプリケーションからAmplify SDKを使って適切にアクセス可能にするという事です。

Amplify CLIを使っていない場合は環境を作成できませんが、Amplify Consoleはブランチ毎に環境変数をデフォルト設定とブランチ毎設定の2種類保持できるので、これを使うことで予め作成されたリソースの識別子を取得してアプリケーションに設定する事で接続が可能です。

画像ではPull Requestが作成された場合のみですが、前述の通りブランチが新規作成された場合も同じ事が行なえます。対象のブランチはブランチ名でワイルドカードを使い指定する事ができます。これによってfeature/*ブランチだけを対象とするといった事が可能です。

Basic認証

デプロイされた環境に対してBasic認証を設定する事が可能です。Basic認証を本番環境の認証として使用するのは機能不足な場合が多く非現実的ですが、開発・検証環境の保護としては最適です。

自動連携されたPull Request・ブランチに対しても事前に設定したIDとパスワードで保護を設定する事が可能です。同じような目的でIPアドレス制限がありますが、Amplify ConsoleはIPアドレスの制限はできません。

リダイレクト設定

あるパスに対するアクセスをリダイレクトする機能です。Single Page Applicationをデプロイする際に必要な機能です。

GEO IPによってエンドユーザーのリージョンを判断しリダイレクトも行えます。

ドキュメントにサンプルが充実しているので、参考にする事で簡単に設定が行なえます。

https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/redirects.html

Amazon Cloud Front + Amazon S3構成と比べて

AWSで静的Webサイトをホスティングする為の方法としては、Cloud Front + S3という構成がより一般的です。

そちらと比べて簡単に、CI/CD環境が非常に簡単にセットアップでき、Basic認証などを利用できるのがAmplify Consoleの利点です。Cloud Front + S3構成だとCI/CDはGitHub Actionsなど外部のサービスやAWS CodePipeline・CodeBuildを使って実現する必要が、Basic認証はLambda＠Edgeを使い実現する必要があります。

逆にAmplify Consoleの劣るところはAWS上でメトリクスが取得できない事です。レスポンスタイムなどは別途外形監視で取得する必要があります。（Cloud Frontなら取得できるメトリクスが取得できない）

ブログを書いている際に「AWS WAFも使えないなー」と思いましたが、静的なコンテンツ自体は保護する必要は無く、保護すべきはAPIなのでこれは問題にならないと思います。